A transport request in a software architecture can refer to a technique via which changes can be recorded and moved across systems. Software architectures, in particular business software architectures such as for example enterprise resource planning (ERP) systems, can in many cases be based on relational database functionality. If changes to the database occur, these changes must be recorded. To move the changes that have been implemented and recorded in one system to another system rather than recreating these changes in the new system, a transport request or similar functionality can record changes to the source system while also generating a unique number or other identifier that can be used to also migrate the transport to the new system. Many business software architectures include functionality to allow a user organization of the architecture to implement one or more customizations to a core software platform provided by a developer of the business software architecture. Such customizations can be added to a system via a customer transport request, where the “customer” is the user organization of the architecture.
A migration of a software architecture or functionality thereof from one physical (or virtual) system to another system can be required under one or more circumstances. For example, during a system upgrade, a “shadow” system can be created on a same system or alternatively on a second system (e.g. on a development system, a test or quality control system, or the like). In some examples, the shadow system can be created on the same system as the productive system. In other words, when a productive system is upgraded, a shadow instance can be created on the computing system that hosts the productive system (either on a same host or on a remote host, but in the same database). The shadow system can receive a copy of a productive system. After the productive system has been copied, the shadow system can undergo the upgrade procedure and be tested for proper operation before the updated architecture is activated for use as the productive system. Such a process generally includes some system downtime even under optimal conditions because the update typically occurs with system downtime followed by an importing of any customer-specific transport requests during further system downtime.